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ABSTRACT 

Mission Activities Planning is a complex task to 
be performed by mission control centers. AI 
technology can offer attractive solutions to the 
planning problem. This paper presents the use of 
a new Al-based Mission Planning System for 
crew activity planning which has been set up in 
the course of an ESA project in cooperation with 
an industrial consortium led by ERNO Raum- 
fahrttechnik. Based on a HERMES servicing 
mission to the COLUMBUS Man Tended Free 
Flyer (MTFF) with complex time and resource 
constraints appr. 2000 activities with 50 different 
resources have been generated, processed and 
planned with parametric variation of operatio- 
nally sensitive parameters. The architecture as 
well as the performance of the mission planning 
system is discussed. An outlook to future plan- 
ning scenarios, the requirements and how a 
system like MARS can fulfill those requirements 
is given. 

Key Words: crew activity planning, time- and re- 
sources constraints, distributed planning, rule 
based planning. 

1. MISSION SCENARIO & OVERVIEW 

The case study conducted is based on a HER- 
MES servicing mission to the COLUMBUS Man 
Tended Free Flyer [ref 1]. The mission scenario 
includes a HERMES launch rate of 2 per year. 
The involved ground segment comprises a Her- 
mes Flight Conrol Center (HFCC), an MTFF 
Control Center (MSCC), a coordinating Combi- 
ned Mission Control Center (CMCC) as well as 
User and Engineering Support Centers. 

Crew activity planning for such type of missions 
has to consider the following main aspects: 

o the HERMES spaceplane system: 

- launched by an ARIANE 5 launcher 

- Mass of payload 3.0 metric tons 


- nominal mission duration: 10 days (Free 
Flyer Servicing: 6 days) 

- 3 crewmembers (commander, pilot, mission 
engineer) 

o the Man Tended Free Flying Laboratoiy. 

- 2 segment Pressurized Module (PM) for 
accomodation of 16 P/L racks (12 m 3 ) 

- Resource Module (RM) docked to PM 

- Propulsion subsystem for altitude and 
attitude control 

- ARIANE 5 launch vehicle 

o MTFF servicing concept: 

- Corrective/Preventive Maintenance 

- Replenishment of consumables 

- Inspection and cleaning 

- Implementation of growth features 

- P/L Upgrading, repair, reconfiguration & 
replacement of payload facilities 

- P/L Resupply and collection of samples & 
consumables 

- P/L Checkout and set-up of P/L processes 

- Servicing by IV A, EVA, Remote Ma- 
nipulation and combined EVA and 
Remote Manipulation activities. 

o Mission Cargo Sets includes all serviceable 

items for a single servicing mission, including: 

- permanent travellers (to be flown each mis- 
sion) 

- life limited items (to be exchanged at end 
of life) 

- stochastic items (corrective maintenance) 

- consumables (e.g. gases & fluids) 

- airborne support equipment (ASE) & tools 

2. THE PLANNING APPROACH 

Crew tasks like internal servicing of subsystems 
or payloads, external servicing of subsystems, 
crew sustaining operations, etc. can be broken 
down into subtasks and activities. The resulting 
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hierarchical structure of crew activities has to be 
converted into a planning database which can 
then be accessed by the planning system. 

The nodes of the planning database contain all 
the relevant planning information, like: earliest 
and latest start time, permissible time window, 
used resources (power, crew member, sun / 
eclipse phases, communication channels, etc.), 
antecedent links to other activities etc. 
Resources are specified by : name, type, avail- 
ability and max capacity. 

The idea is first to build a generic planning 
database which can serve as a library of generic 
tasks, subtasks and activities to be copied for re- 
use and customization for a specific mission, thus 
to reduce significantly the effort for the compila- 
tion of planning data. The contents of the speci- 
fic database depends totally on the Mission 
Cargo Sets. 

Consistency checks of the specific DB (e.g. 
missing or inconsistent antecedent links) are 
supported by the planning system itself. 

Such a system can be easily used as a valuable 
tool for quick assessment of design changes by 
planning with parametric variation of operational 
sensitive parameters. 

3. THE PLANNING SYSTEM 

3.1 The MARS Scheduling System 

The scheduling of the activities selected for a 
specific mission was performed by means of the 
AI based mission planning tool MARS (Mission 
Activities and Resource Scheduler [ref 2]) devel- 
oped by ERNO Raumfahrtechnik GmbH. The 
design of MARS explicitly takes into account the 
complexity aspects of current and future space 
missions. It has been steadily evolved in tight 
cooperation with operational users. Within the 
ESTEC contract NEPTUNE (New Expert System 
for Users in a Network Environment [ref 3]) 
MARS was enhanced by more general resource 
handling capabilities, a rule system, configuration 
management features and distributed planning 
capabilities. It now includes all features necessary 
to successfully apply it not only to space missions 
planning but to any kind of large project schedu- 
ling. 

The main modules of MARS comprise the Data- 
base Editor and the Scheduler each of which will 
be briefly described in the following. 

The Database Editor is a graphical interactive 
tool to allow the efficient creation and modifica- 
tion of activity and resource descriptions, rules to 
direct the scheduling process and constraints. 
Activities are hierarchically structured as ex- 


plained in chapter 2 and handled by the Activity 
Editor [Fig. 1], 

Activities are described by the following major 
attributes: 

o Full activity name and abbreviation, position 
in the activity hierarchy, 
o Earliest and latest possible start time and 
due date (if fixed by problem at hand), 
o Minimum and maximum duration, 
o Any number of antecedent activities and min/- 
max delay times to them (logical dependen- 
cies). 

o Priority, keywords and comments by the user, 
o Interdependencies to other activities (mutually 
exclusive set of activities), 
o Any number of resource requests in the form 
of: resource-name and resource request 

profiles. 

The Resource Editor allows the specification of 
resources as well as the generation of resource 
availability profiles. Any number of different re- 
sources can be introduced by the user. Each re- 
source can be of one of the following types: 

o Sharable resources represent system states. 
E.g. the execution of several activities can 
be restricted to happen during certain day 
or night periods (SUN-ECLIPSE Phases), 
o Depletabie resources can be used to des- 
cribe incremental consumption of a given 
capacity, e.g. Battery or Storage Place, 
o Reusable resources can only be used by one 
user at a time but are available afterwards, 
e.g. Tools and Energy. Conventional project 
planning tools only provide this single type 
of resource. 

o Tri-state resources allow to specify mutually 
exclusive sets of activities (e.g. activities of 
one set cannot run in parallel with activities 
of another set). It is a combination of shara- 
ble and reusable. 

Optionally resource requests can be defined that 
are used permanently even after termination of 
the given activity. Resources can also be generat- 
ed by activities. Additionally a calendar defining 
the general working hours and off days can be 
defined as in any conventional project planning 
system. 

For the generation of schedules and timelines 
adhering to all given constraints a set of rules 
(heuristics) can be specified using the Rule Edi- 
tor. Those rules influence or direct the schedul- 
ing process. E.g. it is possible to schedule in 
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Fig. 1 The Activity Editor 


priority a selected set of activities or to schedule 
in priority the most resource consuming activi- 
ties. Using this feature of MARS the user is very 
flexible in defining his/her own preferences or 
goals to be achieved by the scheduling process. 

Four different rule types exist: 

o Scheduling Rules, which select the set of acti- 
vities for the next pass of the scheduling pro- 
cess. 

o Activity Selection Rules, which influence the 
selection of the next to be scheduled activities, 
o Rescheduling Rules, which influence the re- 
scheduling process and 

o Backtracking Rules, which direct the schedu- 
ling process during backtracking situations. 

Scheduler 

The basic problem in any scheduling process 
involving (limited) resources is defined by the 
requirement to satisfy both temporal and re- 
source constraints simultaneously. 

For MARS therefore a new method has been 
developed, called Time Constraints Propagation 
Mechanism (TCPM), that transforms all symbol- 
ic time constraints on and between activities into 


a computationally much more efficient algebraic 
representation covering all time relations defined 
between activities. At first "time constraint wind- 
ows" are computed for each activity with respect 
to the totality of all temporal constraints imposed 
on the plan. Scheduling of activities only within 
these time windows guarantees that no temporal 
constraint conflicts will occur at any point in the 
scheduling process. Thus futile attempts to sche- 
dule activities outside these windows are avoided, 
thereby speeding up the scheduling process 
considerably and increasing the chance of gener- 
ating a conflict-free schedule. It is the task of the 
TCPM to compute and dynamically update these 
permissible time windows after each scheduling 
step. 

This separation between handling time and 
resource constraints leads to a scheduling strate- 
gy whereby at each point in time, starting from 
left to right on the time axis, only those activities 
which lie within their permissible time windows 
and whose resource and target requests are 
satisfied by the resource and target availability 
profiles for the total duration of the activity are 
identified. Obviously each of these activities 
individually represents a candidate for schedul- 
ing. However, usually not all candidates can be 
scheduled simultaneously, but only candidate 
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subsets. To influence which subset is assigned the 
highest priority for being scheduled the user can 
tailor the involved heuristics with the help of the 
rule system mentioned above. Activities whose 
resource requests cannot be met at that particu- 
lar scheduling step are shifted in time to the 
beginning of their next "resource window", where 
their resource request can be fulfilled, but stay- 
ing within their computed time window. 

In this way generating timelines and schedules 
with MARS can proceed fully automatically, fully 
interactively where the operator selects each 
activity to be scheduled, or in a "mixed mode". In 
all modes the user can follow the dynamically 
unfolding scheduling process graphically on the 
"temporal level". At any point in the scheduling 
process one is able to re-edit activities or re- 
source availability profiles, perform backtrack 
operations and call up conflict inspection dis- 
plays, such as: 

o Display of the schedule and composite 
timelines in the form barcharts and Gantt 
diagrams. 

o Resource Usage, giving the percentage re- 
source exploitation over the total mission 
time (as an indication of the schedule quali- 
ty)- 


o Any type and duration of resource violations 
and involved activities are graphically dis- 
played. 

o The user tan graphically shift an activity 
forward or backward in time and view the 
induced conflicts (or conflict-free areas for 
scheduling) dynamically displayed by the 
"co-moving" scheduler (on forward shift) or 
Backtrack Module (on backward shift). 

A typical example of a schedule generated by 
MARS is depicted in Fig. 2. 

3.2 The Mission Database 

To demonstrate the ability of MARS to interact 
with different types of already existing or future 
mission specific data (e.g. configuration and plan- 
ning data) and to support the concept of a 
generic planning database the mission planning 
data for this project has been stored in an exter- 
nal database whose structure reflects the fore- 
seen COLUMBUS Mission Database Application 
(MDA). For this purpose the Mission Database 
Application Software (MIDAS) was developed 
based on the commercial ORACLE DBMS to 
provide MARS with the required data. The 
information maintained by MIDAS consists of: 



Fig, 2 MARS Scheduler 
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o all scheduling relevant data, such as activity 
and resource definitions, resource availabili- 
ties, generic library of tasks and subtasks 
and Master Timelines (MTLs) as the result 
of the scheduling process, 
o and support data, such as the description of 
the Mission Cargo Sets (MCS) and ORA- 
CLE relevant data (database dictionary). 

MIDAS allows the interactive data entry and 
maintenance. It supports the hierarchical name 
tree concept which provides for expressing the 
relation of objects in a tree like structure. Plan- 
ning data for a specific mission can be generated 
by instantiating the generic activity descriptions 
depending on the selected mission cargo set. A 
version concept was implemented to allow track- 
ing of data changes over time and provide access 
to actual or older versions of database item 
descriptions. Database access control features 
provide limited data manipulation privileges for 
certain data to certain user groups. Finally report 
generation, database recovery and consistency 
check functions have been implemented. 

3.3 The Toolset Architecture 

Since the MARS system and the MIDAS applica- 
tion were intended to be used in a distributed 
environment running on different physical machi- 
nes (for this project MARS ran on a Symbolics 
Ivory LISP coprocessor board residing in a SUN 
4/330 with the Genera 8.0 operating system whe- 
reas MIDAS was running on a SUN 3 with Su- 
nOS 4.03) interface S/W was developed to allow 
communication between MARS and MIDAS in 
a client - server architecture. 
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Fig. 3 Toolset Architecture 

Both machines were connected by Ethernet utili- 
sing the Network File System (NFS) S/W from 


SUN which also supports Remote Procedure 
Calls (RPCs). Using this mechanism data can be 
exchanged between MARS (as the client) and 
MIDAS (as a database server). For example if 
MARS wants to read data from the database it 
specifies as input parameters for a READ RPC 
the type (key) of data and those requested data 
are transfered as return parameters. To perform 
the execution of the RPCs on the SUN a server 
software was implemented. This server handles 
the execution of all the specified procedures. It 
accesses the database via SQL statements. The 
complete architecture is depicted in Fig. 3. The 
server and all remote procedures are imple- 
mented in PRO*C or directly in C, while the 
calling of procedures from within MARS is 
implemented in LISP. 

4. PLANNING DATA ANALYSIS 

The approach to generate planning data includes 
3 main steps: 

o Definition of generic crew activities library 
which can be reused for any mission cargo set. 
o Definition/selection of the mission cargo set to 
be transported by HERMES and operated by 
the crew including all items for: 

- a selected nominal MTFF servicing mission 

- a selected MTFF contingency mission 

o Definition of specific crew activities database 
based on generic data and the selected mission 
cargo set. 

Only those crew activities were subject for plan- 
ning which start with docking of HERMES to 
MTFF and ending with de-docking of HERMES. 

4.1 Generic Operations Definitions 

All generic crew activities have been structured 
hierarchically into phase, task, subtask and 
activity level. The 1st level of the resulting crew 
activities breakdown is shown in Fig. 4. 



Fig. 4 Activity Breakdown (1st Level) 


The complete breakdown resulted in a total of 
80 subtasks and 431 generic activities. An exam- 
ple of the activities breakdown established for 


169 






the exchange of a failed video modulator (inter- 
nal servicing of communication subsystem) is also 
given in Fig. 1. 

4.2 Mission Cargo Sets 

The required items/tasks to be instal- 
led/accomplished by the crew are determined by 
the HERMES and MTFF system capabilities as 
well as by the servicing concept, strategy and 
constraints (see chap.l). The 20 Mission Cargo 
Sets (MCS) for the first 10 years of operation 
have been generated by means of a Monte Carlo 
Simulation. Out of these a representative MCS 
has been selected for the detailed planning. 

For the 114 ORU's of the selected mission a 
rough accomodation analysis to derive the opera- 
tional properties of the different ORU's has 
been performed including an Exchange Task 
Time Assessment as well as an ORU criticality 
analysis to derive priority information to be used 
by the planning system in case of conflicts. 

43 Specific Operations Definition 

Based on the generated MCS information a mis- 
sion specific database has been set up. The major 
steps were: 

o definition of a suitable task structure to allow 
the re-use of the existing substructures of the 
generic database to the extent possible, 
o setup of the lower level task/activities structu- 
res by. 

- importing 

- modification 

- duplication 

as appropriate for the specific mission 
demands, 

o tuning of the generic planning information im- 
ported from the generic database according to 
the mission specific constraints, e.g. time con- 
straint information, resources and resource 
usage, 

o specification of the resource availabilities, 
o definition of the targets (orbital opportunities) 
in the form of time-histories. 

The resulting mission specific database includes 
32 Tasks, 399 Subtasks and 1741 Activities. 

The same exercise was performed for a contin- 
gency mission which has been based on the 
nominal mission defined before. The assumptions 
for this mission have been: 

o repair of a micro meteorite impact in the 
outer shell of the MTFF 


o repair to be performed by means of EVA 
o exact location and extent of the problem is not 
known a priori, thus requiring inspection 
activities with remote manipulator 
o specific repair tools had to be included 

The database for this mission includes 24 Tasks, 
252 Subtasks and 966 Activities. 

5. CREW WORKLOAD ANALYSIS 

The generation of conflict free schedules of acti- 
vities defined in the mission database has been 
performed for the nominal as well as for the 
contingency mission. 

Another important analysis was the variation of 
operationally sensitive parameters in order to 
investigate selected contingency scenarios and 
options to change mission rules. 

For the nominal mission the following variations 
of operationally sensitive parameters have been 
performed: 

o Crew Task Change 

The Mission Engineer has been removed from 
all subsystem servicing activities and the Pilot 
and Commander got the same priority to per- 
form subsystem servicing, 
o MCS Reduction 

Some cargo items could not be accomodated 
physically in HERMES. The corresponding 
crew activities have been removed from the 
schedule, 
o Crew Sickness 

The Mission Engineer is not available on the 
first servicing day for about 4 hours due to 
space sickness, 
o Communication Dropout 
RF - Communication between HERMES / 
MTFF and ground is interrupted for 3 hours 
on the 4th mission day. 

The generated schedule for the nominal mission 
showed that with the a priori defined crew 
allocation to the mission activities only 35 % of 
the science payloads could be processed. Valu- 
able statistical functions for exploitation of the 
available crew resources resulted in the following 
numbers: 

o Commander = 61.6 % 
o Pilot = 62.9 % 
o Mission Engineer = 84.9 % 

These numbers gave indications to assign more 
tasks in the science payload area to the 
Commander and to the Pilot, which resulted in 
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Tab.l Summary of Planning Results 

a 100 % accomplishment of all tasks. Table 1 
indicates the results obtained by the other varia- 
tions. 

6. OTHER SYSTEM APPLICATIONS 

MARS has shown its versatility and operational 
capabilities in a number of different application 
areas. The first important application field was 
the planning of manned and unmanned space 
missions on tactical as well as on executional 
level. This also covers the application as descri- 
bed in this paper. Furthermore, MARS was used 
to perform dynamic payload accomodation based 
on information contained in payload configura- 
tion databases (such as the COLUMBUS P/L 
Database CPDB) and to analyse alternative 
accomodations [ref 4]. 

In a study on future autonomous space systems 
MARS was used as a budding block for autono- 
mous scheduling and rescheduling. Complement- 
ed by a diagnosis system and spacecraft simulator 
the system was able to demonstrate the capabili- 
ties of a fully autonomous spacecraft that reacts 
to malfunctions by diagnosing its internal status, 
initiates appropriate recovery actions and finally 
replans the rest of its mission according to the 
new situation [ref 5]. 

Current activities comprise the development of 
interface software and the rework of planning 


data originally compiled for the MIPS (Mission 
Planning System) used to plan the next German 
Spacelab Mission (D2) to be launched early next 
year. For this application MARS is intended to 
be validated during the mission in terms of its 
performance and operational capabilities by 
comparing MARS with the built-in scheduler 
(ESP, Experiment Scheduling Program) of the 
MIPS system in replanning situations. For this 
purpose MARS is extended to be able to deal 
with the same input and output data formats as 
the ESP system. Former studies have already 
shown the advantages of MARS as an automatic 
and interactive scheduling tool wrt ESP, but this 
will have to be justified during that real mission. 

Another recent project is the utilisation of 
MARS for the planning of the ARIANE4 second 
stage and booster production and integration 
that is performed at ERNO premises. 

Under the product name PARS (for Project Acti- 
vities and Resource Scheduler) the MARS 
system will also be made available commercially 
on SUN workstations until end of this year. 

Distributed Planning 

The COLUMBUS mission planning concept is 
currently still under definition. MARS can 
support an operational scenario which is based 
on two important principles: 
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o the distributed Ground Segment Infrastruc- 
ture and 

o the hierarchical system for its management 

According to the hierarchy of the distributed 
planning environment there will exist a tree 
structure of logical nodes each with its own 
MARS system, each responsible for the planning 
of a specific logical node or mission center in the 
hierarchy. Within a logical node the activities are 
structured itself in a tree hierarchy as described 
for the mission planning database editor. In a 
top-down procedure each center allocates re- 
source envelopes to its lower level centers over 
the network, so that these can generate their 
own local schedules and timelines. Afterwards 
these local timelines will be integrated in a 
bottom up approach into the higher level 
timelines. This MARS features can also be 
applied to any type of project planning, where 
the problem at hand must be decomposed and 
solved by severalplanning teams, working closely 
together. 

7. CONCLUSION 

The results of the project have clearly shown that 
such a planning system can be an essential tool 
throughout the lifecycle of a space project, 
starting with the initial definition of the space 
infrastructure until and within the operational 
phase. In the very early project phases trade-offs 
can be performed to assist in the design of the 
spacecrafts and payloads. What-if scenarios can 
be worked out to identify bottlenecks in the 
system design by analysing operational scenarios 
(timelines). 

The planning system used in this study compared 
to other commercially available systems, e.g. for 
project planning, has the ability to handle differ- 
ent kinds of resources, e.g. to handle stocking 
tasks by filling intermediate stores. It can be 
interfaced with other software and databases 
through its programming language interface and 
the possibility exists to extend its intrinsic func- 
tionality to implement any upcoming and very 
specialised requirements, e.g. for additional 
project specific resource types. 

These features would allow the cost effective ap- 
plication of MARS in other very demanding 
scheduling domains where resources are a limit- 
ing factor and the timespan for execution of 
tasks is restricted, such as: 

o Production planning, scheduling of production 
tasks, interleaving of multiple production lines 


o Transportation planning 
o Logistics planning 

Future alternative hardware platforms for the 
planning tool MARS will be any UNIX based 
system that supports a Common Lisp environ- 
ment with multitasking capability and X window 
system interface using CLIM and CLOS (e.g. 
SUN workstations). This will achieve the goal of 
principal hardware independence for MARS and 
derivatives (PARS) and will be finished in 1992. 
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